REMARKS/ARGUMENTS 

Claims 1,18 and 27 are pending in the present application. Claims 1,18 and 27 are 
amended. Support for amendments to the claims may be found in the specification in paragraphs 
[0047], [0048], [0049], [0050], [0053], [0055], [0056], and [0076]. Reconsideration of the 
claims is respectfully requested. 

I. 35 U.S.C. § 101 

The Examiner has rejected claims 1,18 and 27 under 35 U.S.C. § 101 as being directed 

towards non-statutory subject matter. The Examiner states: 

Claims 1,18, and 27 are rejected under 35 U.S.C. 101 because the cMmed 
invention is directed to non-statutory subject matter. Based on the 
Applicant's specification, the recited "repository adapter" of Claim 1 and 
the recited "integrated development environment" of Claim 27 appear to 
be implemented in software. Any claim whose limitations are either 
explicitly claimed as being implemented in software, or could be 
reasonably inteipreted as being implemented in software, must be claimed 
in combination with an appropriate medium to establish a statutory 
category of invention and enable any functionality to be realized in order 
for the claimed subject matter to be statutory under the provisions of 35 
U.S.C. § 101. 

Claim 18 is directed toward a method for collaboratively authoring 
documents. However, for a method to be statutory it must be tied to 
another statutory class (such as a particular apparatus) or transform 
underlying subject matter (such as an article or materials) to a different 
state or thing. Since the claims do not appear to do either of these the 
method is non-statutory. 

Pre-Interview Communication dated March 11, 2009, page 3. 

Applicants have amended claims 1,18 and 27 in compliance with the statutory 

requirements. In particular, claim 1 is directed to an apparatus, claim 18 is directed to a 
combination of a computer implemented method in a computer system and claim 27 is directed 
to a combination of an integrated development environment in a computer system. The amended 
claims are directed toward statutory categories with required transformation of underlying 
subject matter, including the updating of documents through client changes to a document 
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repository maintained on the computer system. Accordingly, claims 1,18 and 27 comply with 
the statutory requirements and overcome the Examiner's rejection. 

II. 35 U.S.C. § 112, Second Paragraph 

The Examiner has rejected claims 1,18 and 27 under 35 U.S.C. § 1 12, second paragraph, 
as being indefinite for failing to particularly point out and distinctly cMm the subject matter, 
which applicants regard as the invention. The Examiner states: 

Claims 1. 18, and 27 contain several instances of limitations such as 
"adapted to", "adapted for", and simply "to" and "for". Such limitations 
indicate nonfunctional descriptive material and are not functionally 
involved in the steps recited. Hence, such descriptive material does not 
distinguish the claimed invention from the prior art in terms of 
patentability. See In re Gulack, 703 

F.2d 1381, 1385,217 USPQ 401,404 (Fed. Cir. 1983); In re Lowry, 32 
F.3d 1579,32 USPQ2d 1031 (Fed. Ck. 1994). 

Pre-Interview Communication dated March 11, 2009, page 3. 

Applicants have amended claims 1,18 and 27 to remove the limitations noted. Amended 
claims therefore provide the desired specificity required of functional descriptive material and 
elements of the claims are therefore functionally involved in the steps recited. Accordingly, 
claims 1,18 and 27 comply with the statute and therefore the rejection of claims 1,18 and 27 
under 35 U.S.C. § 112, second paragraph has been overcome. 

III. 35 U.S.C. § 103, Obviousness 

The Examiner has rejected claims 1,18 and 27 under 35 U.S.C. § 103 as being obvious 
over Hadfield et al. Document Collaboration Using A Common Database . U.S. Patent 
Application Publication 2003/0112273, (June 19, 2003), (hereinafter ''Hadfield') in view of 
Hugh, Method and Apparatus for Sharing Many Thought Databases Among Many Clients, U.S. 
Patent Application Publication 2003/0117434. (June 26. 2003). (hereinafter "Hush") . The 
Examiner states: 
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Claims 1, 18, 27 (A; Figure 2, paragraphs 5-16). A does not explicitly 
disclose, however B discloses communicating to the client a response 
indicating a successful update (B; paragraph 807). 

It would have been obvious to one of ordinary skill in the art at the time 
the invention was made to modify updating, as disclosed by A, to include 
communicating to the client a response indicating a successful update, as 
disclosed by B, in order to provide an improved document collaboration 

system. 

A does not explicitly disclose a WebDAV repository, however it would 
have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify a repository, as disclosed by Hadfield, to 
comprise a WebDAV repository (disclosed in the background of 
Applicant's specification) since WebDAV was a well known system for 
collaborative document management. 

Pre-Interview Communication dated March 11, 2009, page 3. 

The Examiner bears the burden of establishing a prima facie case of obviousness based 
on prior art when rejecting claims under 35 U.S.C. § 103. In re Fritch, 972 F.2d 1260, 23 
U.S.P.Q.2d 1780 (Fed. Cir. 1992). The prior art reference (or references when combined) must 
teach or suggest all the claim limitations. In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 
1974). In determining obviousness, the scope and content of the prior art are. . . determined; 
differences between the prior art and the claims at issue are. . . ascertained; and the level of 
ordinary skill in the pertinent art resolved. Against this background the obviousness or non- 
obviousness of the subject matter is determined. Graham v. John Deere Co., 383 U.S. 1 (1966). 
"Often, it will be necessary for a court to look to interrelated teachings of multiple patents; the 
effects of demands known to the design community or present in the marketplace; and the 
background knowledge possessed by a person having ordinary skill in the art, all in order to 
determine whether there was an apparent reason to combine the known elements in the fashion 
claimed by the patent at issue." KSR Int'l Co. v. Teleflex, Inc., 127 S. Ct. 1727 (April 30, 2007). 
" Rejections on obviousness grounds cannot be sustained by mere conclusory statements; instead, 
there must be some articulated reasoning with some rational underpinning to support the legal 
conclusion of obviousness. Id- (citing In re Kahn, 441 F.3d 977, 988 (CA Fed. 2006))." 

Claim 1 is as follows: 
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An apparatus for the collaborative authoring by a plurality of clients of 
documents for storage in a repository, said apparatus comprising: 

a controller, in a computer system, for processing and responding 
to client requests for authoring said documents, wherein said processing is 
performed in a transactional manner, said documents define a document 
model and said controller maintains a repository adapter document model 
subset from documents processed in accordance with said client requests, 

an asynchronous communicator in said controller asynchronously 
communicates a document model update for updating a respective client 
document model subset maintained by each of the plurality of clients, 
wherein the client requests comprise serialized updates to the repository 
adapter document model to affect changes to selected documents for 
storage to a repository in a persistent storage of the computer system; 

a lock mechanism in said controller locks said selected documents 
stored in said repository, wherein said controller processes said serialized 
updates using a working copy of said selected documents in response to a 
success of setting a lock of said selected documents, 

wherein said controller stores into said repository said selected 
documents successfully processed from said serialized updates, wherein 
said controller communicates to the client the serialized updates indicative 
of a success of the client request, said success defined by the success of 
the locking, processing and storing of the affected selected documents, 
wherein said controller, responsive to a client request for a document 
stored in said repository, sends the document from the repository; and 

wherein said apparatus communicates with said clients, to receive 
client requests and to send client responses to said requests; and 

wherein said apparatus communicates with said repository, to send 
repository requests for authoring said documents and to receive repository 
responses to said requests for processing said client requests wherein the 
repository is a WebDAV repository. 

The teaching of Hadfield and Hugh does not provide a prima facie obviousness rejection 
of claim because the combination, when viewed as a whole, fails to teach each and every claim 
limitation. In particular, Hadfield and Hugh fail to teach the features of an asynchronous 
communicator in said controller asynchronously communicates a document model update for 

updating a respective client document model subset maintained by each of the plurality of 
clients, wherein the client requests comprise serialized updates to the repository adapter 
document model to affect changes to selected documents for storage to a repository in a 
persistent storage of the computer system, and wherein said controller stores into said repository 
said selected documents successfully processed from said serialized updates, wherein said 
controller communicates to the client the serialized updates indicative of a success of the client 
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request, said success defined by the success of the locking, processing and storing of the affected 
selected documents, wherein said controller, responsive to a client request for a document stored 
in said repository, sends the document from the repository. 

With regard to the feature of an asynchronous communicator in said controller 
asynchronously communicates a document model update for updating a respective client 
document model subset maintained by each of the plurality of clients, wherein the client requests 
comprise serialized updates to the repository adapter document model to affect changes to 
selected documents for storage to a repository in a persistent storage of the computer system 
Hadfield teaches contributor software updating a replica of the document in common storage and 
not the original, as in: 



A system and method is provided for document collaboration between a 
managing author using a document management system (DMS), and one 
or more contributing authors. The system includes: a common storage area 
coupled to a plurality of user computer systems via a communications 
network; manager software stored on a first user computer system, where 
the manager software exclusively controls change to a document stored in 
the common storage area; and contributor software stored on a second 
user computer system, where the contributor software provides a proposed 
change to a replica of the document stored in the common storage area. 

Hadfield, abstract (emphasis provided). 



The contributor software of Hadfield is the client. The common storage area as taught by 
Hadfield contains both a copy of the original document and replicas for each client. Further, 
Hadfield teaches manager software that has exclusive control over changes to the document in 
the common storage area as in: 



[0041] FIG. 3 is an example of the collaboration process performed on an 
original document of an embodiment of the present invention. The 

managing author 310 selects an original document (not shown) from the 
DMS and requests edits or comments from N contributing authors, for 
example, contributing authors 312, 314, 318, where N is a natural number. 
The original document becomes revision 320, when the managing author 
requests at least one contributing author for review, e.g., for edits and/or 
comments. The managing author 310 has control of who can access the 
replicas of the original document for editing, commenting, or a 
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combination thereof, by using the DMS. Hence, for example, managing 
author can restrict access by allowing only contributing authors 312 and 
314 to edit (and/or comment) on revision 320, and allow only contributing 
author 312 to edit revision 322. Contributing author 312 edits (or make 
comments to) a replica of the original document and sends back a 
response 330. Contributing author 314 edits (or make comments to) 
another replica of the original document and sends back a response 332. 
The managing author 310 then reviews and accepts or rejects the 
proposed changes by the contributing authors 312 and 314 to revision 
320. The modified revision 320 becomes revision 322. If the managing 
author 310 is satisfied with the changes, then revision 322 is the final 
document 328 and the collaboration process is finished. If the managing 
author decides on another round of review, then revision 322 is sent to the 
contributing authors, e.g., contributing author 312 for edits/comments. 
Contributing author 312 edits a replica of revision 322 and sends back 
response 334. Then contributing author 312 edits the replica again and 
sends back a second response 336. The managing author then reviews and 
accepts or rejects changes from each response to revision 322. Again 
revision 322 becomes the final document 328, if the managing author 310 
is satisfied. Otherwise the managing author 310 may request another 
round of review and modified revision 322 becomes a revision 324 for 
review by the contributing authors. For revision 324 contributing authors 
3 12, 3 14, and 318 edit replicas of the revision 324 document and send 
responses 338, 340, and 342, respectively back to the managing author 
310, and so forth until a final document 328 is produced. 

Hadfleld, page 4, paragraph [0041] (emphasis provided). 



In contrast, the claimed feature does not have manager software to determine acceptance 
of an update by reviewing and accepting or rejecting the suggested change. The changes 
provided in the claimed feature are not "suggestions" as taught by Hadfield. Updates that are 
submitted are applied without the deliberation in contrast to the process as taught by Hadfield. 
Each client does not make a copy of the document as taught by Hadfield. Rather, the clients of 
the claimed feature use a respective client document model subset maintained by each of the 
plurality of clients. Therefore, Hadfield fails to teach the claimed feature. Accordingly, the 
combination of Hadfield and Hugh fails to teach the claimed feature. 

With regard to the feature of wherein said controller stores into said repository said 
selected documents successfully processed from said serialized updates, wherein said controller 
communicates to the client the serialized updates indicative of a success of the client request, 
said success defined by the success of the locking, processing and storing of the affected selected 
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documents, wherein said controller, responsive to a client request for a document stored in said 
repository, sends the document from the repository, the Examiner asserts Hugh teaches the 
feature at: 



[0807] Next, Ghent A begins to modify at least one of the data items (data 
item 1) associated with Thought 1 (step 3400). In order to accomplish this, 
Client A requests from Sei-ver the right to modify that data item 1 (step 
3401). Finding that data item 1 does not appear in its list of locked items- 
meaning that no other Client is presently modifying it) (steps 3402-3403)-- 
the Server permits Client A to make that modification (step 3405). Server 
then "locks" that data item 1 by placing it in the list of locked items, and 
identifies Client A as "owning" that lock (step 3404). So "locking" that 
data item 1 will prohibit subsequent requesting Clients from modifying 
data item 1 until the Server removes data item 1 from its list of locked 
items, once Client A successfully uploads its modification (step 3406), or 
presumably, by timing out if Client A does not upload any modification 
during a pre-defined time period. Once the Server returns a response that 
the update was successful (possibly after checking for intervening locks) 
Client A displays the modified data item 1 (steps 3407-3409), and the 
Server removes data item 1 from its list of locked items. Client B may 
repeat the same process (steps 3410-3419). 

Hugh, page 47 paragraph [0807] (emphasis provided). 



In the cited portion, Hugh teaches the server returns a response that the update was 
successful. In contrast the claimed feature communicates to the client the serialized updates 
indicative of a success controller communicates to the client the serialized updates indicative of 
a success. The claimed feature sends the successful serialized updates to the client. Hugh does 
not teach the sending of the successful updates to the requesting client. Therefore, Hugh does 
not teach the feature. The Examiner notes that Hadfield fails to teach the notification, therefore 
the combination of Hadfield and Hugh fails to teach the feature as claimed. 

Hugh further teaches a synchronization model and therefore teaches away from the single 
consistent repository model of the claimed features, as in: 



[0814] A fully -connected system maintains a single consistent repository 
of data by simply ensuring that only a single node at a time may modify 
that data. But in an environment in which users or their computers may 
not have full-time access to the network, means are needed for 
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periodically synchronizing users' local copies of shared Brain data, 
because those copies become differentiated from the source while they are 
not connected. Such a synchronization method might also be more suited 
than a fully-connected system for instances when a single source of data is 
accessed and modified by a large number of users at once. 
Synchronization allows clients of a heavily used data source to interact 
with their latest copy of that data offline, and synchronize with a shared 
online copy online. General techniques of synchronizing an offline source 
of data with a shared data source available to many notes on a network are 
known in the art. Examples include products such as the Truesync.TM. 
line of computer programs and services offered by Starfish Software, Inc. 
(www.truesync.com) which, among other benefits, permit users to 
synchronized their e-mail, contacts and other data created through Lotus 
Notes or Microsoft Outlook with numerous types of handheld devices 
such as PalmPilots.TM. or personalized online portals like MyYahoo. The 
description below describes applying synchronization techniques to permit 
multiple nodes interact with and modify a shared repository of Brain 
related data, and takes into consideration the unique needs of a network 
structure of data capable of delivering generic or associative data types. 

Hugh, page 48 paragraph [0814] (emphasis provided). 



Therefore, there is no motivation to combine Hugh with Hadfield to achieve the result of 
the claimed feature. Hadfield and Hugh, in combination when viewed as a whole, fail to teach 
the features of claim 1. Under the standard of In re Royka, Hadfield and Hugh fail to provide a 
prima facie obviousness rejection of claim 1. Claims 18 and 27 have similar subject matter to 
that of claim 1 and are therefore also distinguished over the teaching of Hadfield and Hugh. 
Therefore, the rejection of claims 1,18 and 27 under 35 U.S.C. § 103 has been overcome. 



IV. Conclusion 

The subject application is patentable over the cited references. Therefore, the subject 
application should now be in condition for allowance. Applicants invite the Examiner to call the 
undersigned at the below-listed telephone number if, in the opinion of the Examiner, a telephone 
conference would expedite or aid the prosecution of this application. 
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Respectfully submitted. 



/Cathrine K. Kinslow/ 



Cathrine K. Kinslow 
Reg. No. 51,886 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorney for Applicants 
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